Migration, consolidation, virtualization, and cloudification are some of the information technology (IT) transformation tasks, particularly involved with the current era of cost savings and green data centers. In this disclosure, those and the like tasks are collectively referred to as “migration.” A task in migration includes the discovery of dependencies or affinities, i.e., what components (servers, applications, application modules, databases, etc.) depend on what other components. Wave planning, i.e., grouping dependent components together so that they are migrated together and can be tested together in the target environment is another task.
There is yet another step in overall migrating that utilizes the knowledge of dependencies. In migrating to a target environment with different addresses (such as IP addresses or domain names in the context of the Domain Name Service), every configured dependency to a migrated component needs to be changed into the new address. This is referred to as “relinking” in the present disclosure. Relinking is currently done manually, often even without access to a detailed representation of the dependencies in the source environment.
Wrong relinking (typically overlooked dependencies) is a major source of errors that show up later in end-to-end testing and are difficult to identify and fix, thus contributing to long migration schedules and high migration costs. For those reasons, many enterprises continue to shy away from migrations.
Dependency configurations can occur in many places; hence the manual task is indeed large and risky. For instance, in WebSphere™ a dependency can be configured for an application server, an application, or a module such as an ear or jar file, or even (via aliasing) across several of these layers. It may also be configured directly in the Java™ code residing inside the modules.